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In the specification 

On page 1, line 5 after ^'application is" insert - - a continuation of U.S. Patent 
Application Serial Number 09/721,557, entitled, "SYSTEM AND METHOD FOR 
MAINTAINING SECURITY A DISTRIBUTED COMPUTER NETWORK," filed 
November 22, 2000, which is a continuation of 09/248,788 by the same title, filed on 
February 12, 1999, now U.S. Patent Number 6,158,010, which is - 

Delete from page 8, line 3 through page 9, line 9. 

On page 21, line 4 after the word "subject," replace the word "math" with the 
word - - match - 



2 




In the claims 

Cancel claims 8, 16, 23, 29, 33, 35, and 50 without prejudice or disclaimer. 

Add the following new claims 

1 57. The system of claim 1 wherein the computer readable components are associated 

2 with an application and are stored on a computer readable medium. 

1 58. A system for maintaining security in a distributed computing environment, 

2 comprising: 

3 a policy manager for managing a security policy; and 

4 an application guard for managing access to a transaction related with an 

■J ; 

jnii. 5 application as specified by the security policy, 

i'^^^ 1 59. A system to protect computer systems against unauthorized access for managing 

lu 2 and enforcing complex security requirements in a distributed computer network 

^ 3 comprising: 

4 a policy manager located on a server for managing and distributing a policy to a 

5 cUent; and 

6 an application guard located on the client, acting to grant or deny access to 

7 various components of the client, as specified by the policy. 

1 60. The system of claim 59 wherein the server is connected via a network to the 

2 client. 
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1 61. The system of claim 59 wherein the server is connected to many clients. 

1 62. The system of claim 59 the server further comprising: 

2 a central processing unit; 

3 a Read-Only Memory (ROM); 

4 a Random- Access Memory (RAM); 

5 a non- volatile memory; 

6 an input device; and 

7 a display; 

8 wherein the ROM, the RAM, non-volatile memory, input device and display are 

9 connected via a bus. 

1 63. The system of claim 59 wherein the policy manager is a program located on a 

2 server in non- volatile memory. 

1 64. The system of claim 59 wherein the client contains a program stored in non- 

2 volatile memory for granting or denying access to various components or resources of the 

3 client, as specified by the policy distributed from the server, 

1 65. The system of claim 59 wherein the server includes a non-volatile memory, where 

2 the policy manager is located that specifies the security requirements for applications and 

3 database objects; 

4 said policy contains security rules that describe at least one constraint that 

5 constrains 
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6 which applications a particular user can access and 

7 which objects within an application a user can access. 

1 66. The system of claim 65 wherein the policy manager allows the administrator to 

2 choose whether the constraints are effected by any of 

3 time, 

4 geography, and 

5 external events. 

1 67. The system of claim 59 wherein the policy is capable of constraining access to 

2 applications and operations within applications. 

1 68. The system of claim 59 wherein the poHcy is organized into groups and 

2 hierarchies. 

1 69. The system of claim 59 wherein the policy includes access rules, which include: 

2 a grant rule that grants a privilege to a subject on an object under a first constraint; 

3 and 

4 a deny rule that denies a privilege to a subject on an object under a second 

5 constraint, 

1 70. The system of claim 59 the policy manager further comprises 

2 a management station program to operate the poUcy manager, 

3 a distributor program to distribute local client poHcies to cUents, 
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4 a logger program to track authorization requests, and 

5 a database management system (DBMS) to maintain policy data files. 

1 71. The system of claim 59 wherein the policy manager further comprises: 

2 an audit log data file to record authorization requests; 

3 an optimized policy data file; 

4 an enterprise policy data file; 

5 an administrative policy data file; and 

6 a local administrative policy data file. 

1 72. The system of claim 59 wherein the pohcy manager is located within non-volatile 

2 memory. 

1 73. The system of claim 59 wherein the pohcy manager allows system users to 

2 implement, 

3 analyze, 

4 edit and 

5 update 

6 a centrally-managed policy. 

1 74. The system of claim 59 wherein the policy includes at least one poUcy rule 

2 comprising: 

3 1) an object that is to be protected; 

4 2) an access right or privilege; 
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5 3) a global or local user to which the privilege appUes; and 

6 4) conditions under which the privilege is granted or denied, wherein the user is 

7 given a choice of types of conditions including 

8 whether to use built-in access criteria wherein the user can select 

9 whether to use time of day and 

1 0 whether to use location, 

11 and 

12 whether to use custom-defmed access criteria, 

1 75. The system of claim 59 wherein the policy manager comprises a Graphical User 

2 Interface (GUI) that provides at lest a user- friendly set of menu options or management 

3 services to fully operate the policy manager and control programs that perform at least 

4 navigation, 

5 searching, 

6 distribution, 

7 editing, 

8 querying, and 

9 log viewing. 

1 76. The system of claim 59 wherein the policy manager comprises an Application 

2 Programming Interface (API) that at least allows programs to perform the same functions 

3 as a human operator. 
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1 77. A system comprising a computer having a security policy that includes at least 

2 one or more components having at least: 

3 an object, 

4 a subject, 

5 a privilege, and 

6 a condition. 

1 78. The system of claim 77 wherein each object can be an application or an operation 

2 within an application. 

1 79. The system of claim 77 wherein the object is capable of being set to be at least 

2 any of: 

3 an application, 

4 a method, 

5 a web page, 

6 a database table 

7 a file, and 

8 one or more menu items in a graphical user interface. 

1 80. The system of claim 77 wherein the object can be organized into at least an object 

2 hierarchy such that: 

3 if a user is granted a certain privilege on a parent object, then that user is 

4 automatically granted the privilege on all the children objects, and 



8 



5 if the user is denied a certain privilege on a parent object, then that user is denied 

6 the privilege on all the children objects, 

1 81 . The system of claim 77 wherein the privilege is capable of being inherited from a 

2 parent to a child obj ect, 

1 82, The system of claim 77 wherein the subject is capable of being set to be at least 

2 any of: 

3 a user and 

4 ' a role containing one or more users, 

5 who can at least 

6 access a protected object, and 

7 have access to at least some information in the system, 

1 83. The system of claim 77 wherein the subject is capable of being a user that can be 

2 chosen to be either internal or external to a system, 

1 84. The system of claim 77 wherein the object comprises a hst that is capable of 

2 containing one or more users authorized to access the object who can log on to the object 

3 and be authenticated by the object through an external authentication server. 

1 85. The system of claim 77 wherein the system is capable of having the subject be a 

2 user who at least: 
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3 can be maintained separately by one or more components each of which can be an 

4 object or directory server; and 

5 can be extracted Jfrom said one or more components to synchronize the 

6 components thereby maintaining their access current. 

1 86. The system of claim 77 wherein components comprise an alias-user who at least 

2 inherits all privileges of a user under certain conditions, thereby facilitating authorization 

3 management by providing fine granularity of control on propagation of a privilege. 

1 87. The system of claim 86 wherein the system is capable of having the alias-user be 

2 created to perform a job function while the user is absent, and inheritance of the privilege 

3 takes effect only when the user is absent. 

1 88. The system of claim 77 wherein a user of the object is capable of being defined to 

2 be local to the object. 

1 89. The system of claim 77 wherein a user can be at least a global user mapped to a 

2 set of local users having at least one local user per object. 

1 90. The system of claim 77 wherein the privilege defines at least one kind of access 

2 that is allowed to the object and includes at least one right to perform a particular action 

3 on the object. 

1 91 . The system of claim 77 wherein the privilege is capable of including at least 
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2 a right to execute an application, 

3 a right to download a web page, 

4 a right to query a database table, or 

5 a right to view a menu item. 

1 92. The system of claim 77 wherein the component is capable of being assigned to be 

2 a wild card that is capable of being used at least as a privilege, object, or subject. 

1 93. The system of claim 77 further comprising an access request that includes at least: 

2 a privilege, 

3 an object, and 

4 a subject; 

5 wherein the access request is used by at least a subject to request authorization of 

6 at least a privilege on at least an object. 

1 94. The system of claim 93 wherein the access request at least: 

2 matches a grant rule if the privilege, object, and subject match those in the rule, 

3 and the constraint in the rule is met; and 

4 matches a deny rule if the privilege, object, and subject match those in the rule, 

5 and the constraint in the rule is not met. 

1 95. The system of claim 77 wherein an access request is at least: 

2 denied if 

3 there is a deny rule matching a request, or 
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4 there are no access rules matching the request; and 

5 granted if there are no deny rules matching the request and there is a grant rule 

6 matching the request. 

1 96. The system of claim 77 wherein conditions comprise constraints and the system 

2 having at least facilities for defining constraints as expressions formed from operators 

3 including at least NOT, AND, and OR. 

1 97. The system of claim 77 wherein conditions at least: 

2 are constraints on when the object or the subject can be accessed, 

3 specify requirements on when the access rule is apphcable, and 

4 contain options that can be set to be dependent on properties of the object or the 

5 subject, 

1 98. The system of claim 77 wherein the system further comprises facilities for 

2 expressing constraints as at least: 

3 1) relational operations on integers; 

4 2) relational operations on strings; and 

5 3) set operations. 

1 99. The system of claim 77 wherein the system further comprises facilities that allow 

2 the user to define conditions. 
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1 100. The system of claim 77 wherein the system includes an Application Programming 

2 Interface (API) for invoking user-supplied code to evaluate user-defined functions. 

1 101. A system comprising a computer having a security policy that includes at least 

2 one or more components having at least a set of privileges that includes at least one 

3 privilege that is capable of at least: 

4 being granted to the user explicitly; and 

5 being granted to a role which is granted to the user. 

1 102, The system of claim 101 wherein: 

2 the role is a named group of privileges containing at least one privilege that are 

3 granted to at least one user or to at least one other role; and 

4 the at least one user granted to the role is a member of the role. 

1 103. The system of claim 101 wherein the members of a role automatically inherit all 

2 the privileges granted or denied to the role, 

1 104, The system of claim 101 wherein roles are organized into a role hierarchy, where 

2 parent roles are granted to children roles such that: 

3 if a parent role is granted a privilege, then the children roles are automatically 

4 granted the privilege; and 

5 if a role is denied a privilege, then the children roles are automatically denied the 

6 privilege. 
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1 105. The system of claim 101 wherein roles of an object may be defined as being local 

2 to that object, 

1 106. The system of claim 101 wherein the role is at least a global role mapped to at 

2 least a set of local roles, having at least one role per object. 

1 1 07. The system of claim 101 wherein the system further comprises more than one 

2 role, two of which have memberships that are mutually exclusive with respect to one 

3 another. 

1 108. The security system comprising a policy manager located on a computer system 

2 that includes at least: 

3 a management console or station; 

4 a database management system; 

5 an audit faciUty; and 

6 a distributor. 

1 1 09. The system of claim 108 wherein the management station further comprises a 

2 Graphical User Interface (GUI) for creating and customizing rules by system users. 

1 110. The system of claim 1 08 wherein the management station supports concurrent 

2 rule development by multiple users. 
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1 111. The system of claim 1 08 wherein the management station includes an application 

2 guard to allow only authorized administrators to operate the management station based on 

3 at least a local administrative policy which provides a set of policy rules specifying which 

4 users are authorized to access management station. 

1 112. A security system comprising: 

2 at least one application guard stored on a computer readable medium and guards a 

3 protected application by preventing unauthorized transactional access to at least a portion 

4 of said apphcation, 

1 113. A security system comprising: 

2 an application guard located within non- volatile memory that is designed to reside 

3 along with each protected application and supports transactional access control by 

4 allowing an application to detect an authorization service and to make authorization 

5 requests at each user interaction, data request, and business-level transaction. 

1 114. The security system of claim 1 13 further comprising a distributor capable of 

2 distributing the application guard on chents throughout an enterprise. 

1 115. The system of claim 1 1 3 wherein the application guard is integrated into the 

2 application through an application programming interface (API) or authorization library 

3 that allows the application to request authorization services as needed through an 

4 application guard interface. 
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1 116. The system of claim 113 further comprising 

2 an authorization engine that processes an authorization request;, 

3 a checker that parses local client policy and stores the parsed local client policy in 

4 Random Access Memory (RAM); and 

5 an evaluator that determines whether the authorization request should be granted 

6 or denied by evaluating the authorization request with the parsed local client policy in 

7 RAM. 



1 117. The system of claim 113 wherein the authorization engine comprises plug-ins that 

2 at least allow for additional capabilities to process and evaluate authorization requests 

3 based on customized code. 

1 118. The system of claim 113 further comprising a logger where at least: 

2 each authorization request is then recorded in an audit log; and 

3 each authorization request made at a location remote from the logger is 

4 transmitted to the logger via a communication interface. 

1 119. The system of claim 113 wherein the system is capable of implementing at least: 

2 the application guard locally to the application; and 

3 the appUcation guard as a remote authorization service through a remote 

4 procedure call to another server. 
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1 120. A security system comprising: 

2 at least one application guard stored on a computer readable non- volatile memory 

3 medium that is designed to reside along with each protected application and 

4 guards a protected application by preventing unauthorized transactional 

5 access, and 

6 supports transactional access control by allowing an application to detect 

7 an authorization service and to make authorization requests at each user 

8 interaction, data request, and business-level transaction; 

9 wherein 

10 the apphcation guard is integrated into the application through an 

1 1 apphcation programming interface (API) or authorization library that allows the 

12 application to request authorization services as needed through an application 

1 3 guard interface, and 

14 the system is capable of implementing the application guard locally to the 

15 application and is capable of implementing the application guard as a remote 

16 authorization service through a remote procedure call to another server. 

1 121 , A computer readable storage medium having stored thereon a method for 

2 maintaining security in a distributed computing environment comprising the steps of: 

3 managing a security pohcy via a policy manager; and 

4 managing access via an apphcation guard to a transaction related with an 

5 application as specified by the security policy. 
6 



17 




7 122. A method for maintaining security in a distributed computing environment, 

8 comprising: 

9 managing a security policy via a policy manager; and 

10 managing access via an application guard to a transaction referenced by an 

1 1 application as specified by the security pohcy. 

1 123. A method of using a security system comprising: 

2 using a management station to create or modify a policy rule 

3 distributing the poHcy rule to appropriate cUents via a communication interface 

4 included in the management station. 

1 124. The method of claim 123 further comprises reviewing and reconstructing the 

2 policy rules via a parser to make sure that the poHcy rules are syntactically and 

3 semantically correct according to a predefined policy language. 

1 125. The method of claim 1 23 further comprises determining via a differ-program the 

2 changes were made to optimized the policy, and wherein the step of distributing then 

3 distributes only the changed policy rules or local client policy to the appropriate 

4 application guards, which enforce access control to local applications and data. 

1 126. The method of claim 123 wherein each appHcation guard has its own specific 

2 local client policy. 
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1 127. The method of claim 123 further comprising optimizing via the distributor an 

2 administrative policy into an optimized administrative policy or local administrative 

3 policy for use with an application guard in the management station. 

1 128. The method of distributing at least one security poHcy rule comprising: 

2 passing the policy rule through at least 

3 a DataBase layer (DB layer) and 

4 an Open DataBase Connectivity layer (ODBC); 

5 and 

6 storing the pohcy rule as an enterprise policy. 

1 129. The method of claim 128, wherein: 

2 the DB layer formats the policy rules into standard database storage tables, and 

3 the ODBC provides a common interface to various vendor-specific databases. 

1 130. The method of claim 128 wherein the distribution occurs through the ODBC layer 

2 and a communication interface. 

1 131, The method of claim 128 further comprising passing the enterprise policy to a 

2 distributor. 

1 132. The method of claim 128 further comprising determining via an optimizer 

2 program within the distributor which application guard needs to receive the policy rules. 
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1 133. A method of configuring a security system comprising: 

2 installing a policy manager on a server including 

3 installing 

4 a management station, 

5 a distributor, 

6 a logger, and 

7 a DataBase Management System (DBMS); 

8 entering a set of policy rules 

9 installing application guards and local client policies onto client systems; and 

10 registering plug-ins into the application guards to allow for additional capabilities 

1 1 in order to process authorization requests based on customized code. 

1 134. The method of claim 1 33 wherein the step of entering includes presenting an 

2 administrator with the choice of whether to use a policy loader or management station to 

3 enter the policy rules. 

1 135. The method of claim 133 wherein 

2 if the administrator chooses to use the management station, then the step of 

3 entering includes using an edit function to enter the policy rules, and 

4 if the administrator chooses the policy loader, then the step of entering 

5 includes entering the pohcy rules into a file, and 

6 passing the file to the policy loader. 
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1 136. A method of managing policy under management services in a management 

2 station comprising: 

3 an authorized administrator logging into a policy manager; 

4 the authorized administrator chooses between administrative mode to manage 

5 administrative pohcy or enterprise mode to manage enterprise pohcy; 

6 presenting the administrator with menu options including 

7 navigate tree, 

8 analyze policy, 

9 edit pohcy, 

1 0 distribute policy, 

1 1 view audit log which is a security feature that allows an administrator to 

12 view and track authorization requests have occurred at an apphcation guard 

13 connected to a system, and 

14 exit. 

1 137. The method of claim 136 wherein menu option navigate tree provides a set of edit 

2 options for an administrator that include to 

3 add, 

4 delete, and 

5 modify features; 

6 wherein the administrator is presented with a choice of features on a server and on 

7 a client. 
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1 138. The method of claim 1 36 wherein the features that the administrator has the 

2 option apply the edit options include 



3 global users, 

4 global roles, 

5 directories, 

6 local roles, 

7 local users, 

8 apphcations, 

9 application guards, and 
10 declarations. 



1 139. The method of claim 136 wherein the menu option analyze policy allows an 

2 authorized user to analyze and view rules and policies within enterprise policy. 

1 140. The method of claim 136 wherein the user is presented with an option to 

2 search rules, and 

3 to query policy. 

1 141 . The method of claim 140 wherein if search rules is selected, the administrator is 

2 presented with options of searching grant rules and all the deny rules pertaining to a 

3 particular user. 

1 142. The method of claim 140 wherein if query policy is selected, a search can be 

2 made on who is granted or denied what privilege on which objects under what conditions. 
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1 143. The method of claim 140 wherein the menu option edit poHcy presents an 

2 authorized user with the option to add, delete, and modify enterprise pohcy features. 

1 144. The method of claim 143 wherein the features that may be edited include 

2 a rule set, 

3 access, 

4 a privilege, 

5 an objects, 

6 an user 

7 a role, and 

8 an attribute. 

1 145. The method of claim 136 wherein the menu option distribute pohcy includes 

2 distributing the new features of a newly entered or modified enterprise policy to 

3 appropriate application guards. 

1 146. The method of claim 136 wherein upon selecting the distribute policy option 

2 a distributor optimizes enterprise policy; 

3 a differ program computes a difference between a newly optimized policy and a 

4 former optimized policy; 

5 the newly optimized policy is then published as optimized pohcy in DBMS; 

6 committing only the changed portions of the newly optimized policy to an 

7 appropriate apphcation guard; 

8 the application guard receives the newly optimized policy; 
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9 the application guard merges the newly optimized policy into local client policy; 

10 and 

1 1 the local chent policy is activated to work with the application guard. 

1 147. A method of granting chent access authorization comprising: 

2 using an application guard that includes at least 

3 requesting access to a software securable component associated with an 

4 application protected by an application guard, wherein the appUcation guard 

5 constructs and issues an authorization request, and 

6 evaluating the authorization request via the application guard according to 

7 its local client policy to determine whether to allow or deny the authorization 

8 request; and 

9 an audit records the authorization request in an audit log; 

10 wherein 

1 1 if there is an error in the authorization request, or if the request is 

12 not valid, then the user is denied access; 

13 if the authorization request is vahd, then a determination is made 

14 whether access should be granted, and 

15 if the evaluated authorization request does not deny access 

16 for the user, then access is allowed, and 

17 if the evaluated authorization request denies access for the 

1 8 user, then access is denied. 
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1 148, The method of claim 147 wherein evaluating the authorization request includes an 

2 evaluator searching deny rules in local poHcy 

3 if the evaluator finds a deny rule, then an evaluation is performed on any 

4 constraints on the deny rule 

5 if the evaluation finds a presently valid constraint on the deny rule, 

6 then access is denied, and 

7 if the evaluation finds that all constraints on the deny rule are not 

8 presently vaUd, then a search for a grant rule is performed; 

9 and 

10 if no deny rules are found, then a search for a grant rule is performed; 

1 1 wherein after a search for a grant rule 

12 if no grant rule is found that would allow access for the user, then 

13 access is denied, and 

14 if a grant rule is found, then an evaluation is performed on any 

1 5 constraints in the grant rules wherein 

16 if the evaluated constraint is presently valid, then access is 

17 allowed, and 

1 8 if the evaluated constraint is not presently valid, then access 

19 is denied. 

1 149. A method for securing a computer system comprising: 

2 guarding a protected application by using an application guard to prevent 

3 unauthorized transactional access. 
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1 150. A method for providing a security system comprising: 

2 providing at least one application guard that is storable on a computer readable 

3 medium and guards a protected application by preventing unauthorized transactional 

4 access to at least a component associated with the apphcation, 

1 151. A method for updating a security system comprising: 

2 updating a set of policy rules containing at least one policy rule in a central 

3 location; 

4 generating changes to the set of policy rules resulting from the updating step; and 

5 distributing the changes to the set of pohcy rules. 

1 152. The method of claim 151 wherein the poUcy rule contains entitlement information 

2 related to at least one resource. 

1 1 53, The method of claim 151 wherein the poHcy rules are stored in a database table. 

1 154. A method for establishing a security system comprising: 

2 establishing a set of policy rules containing at least one pohcy rule in a central 

3 location; and 

4 distributing the set of policy rules for enforcement. 

1 155. The method of claim 1 54 wherein the policy rule contains entitlement information 

2 related to at least one resource. 



26 



156. The method of claim 1 54 wherein the policy rules are stored in a database table. 
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Remarks 

New claims 57-156 are submitted for the Examiner's consideration and are 
unrelated to the prosecution history of parent appHcation, 

Non-allowed claims 1-7, 9-15, 17-22, 24-28, 30-32, 34, 36-49 and 51-56 of the 
parent appHcation are being submitted for reconsideration. 

35 use §103 

The Examiner made statements (the first and last sentences of the paragraph 
bridging pages 3 and 4, the first sentence of the full paragraph of page 6, the last full 
sentence on page 7, the last sentence of the paragraph bridging pages 6 and 7, the first 
and last sentence of the last paragraph of page 9, the first sentence of the paragraph 
bridging page 1 1 and 12, the first and second to last sentence of the full paragraph of 
page 14, and the middle of the last full paragraph of page 17) such as, "It would have 
been obvious. . .to allow Nessett to combine with Minear" (emphasis added) and as such 
used the wrong criterion for obviousness. The Applicants note that obvious "to allow" to 
combine is a standard that is easier to prove than obvious "to try" to combine because "to 
allow" to combine implies a lack of a sufficient motivation to actually combine or even 
try to combine which is present in obvious "to try" to combine. The courts, however, 
have stated that obvious "to try" to combine is an insufficient standard of obviousness 
presumably because it is only a motivation to experiment rather than to actually combine 
and is a easier to meet than obvious to combine (see In re Geiger, 815 F.2d 686, 2 
USPQ2d 1276 (Fed. Cir, 1987) for an example of a case in which "obvious to try" was 
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determined not to be obviousness). It logically follows that obvious "to allow" to 
combine is a forte ore also an insufficient criterion for obviousness under 35 USC §103. 

Minear et al. relates to firewall-to-firewall connections, Minear et al.'s "invention 
is a system and method for regulating the flow of messages through a firewall" while in 
contrast Nessett et al distributes the firewall. 

The Examiner stated, 

Application gateway is known by definition as being software used to maintain 
security on a network. 

However the phrase "application gateway" does not appear in Minear et al. Rather 

Minear et al. refer to an "application level gateway firewall 18." FIG. 1 labels feature 

number 18 as "FIREWALL." Thus the "application level gateway firewall" is just a long 

name for a firewall Minear et al. and Nessett et al. discuss protecting unauthorized entry 

into nodes of repeaters and switches for example rather than unauthorized entry into 

applications and items associated with applications. The Applicants respectfully submit 

that the Examiner is apparently ignoring the word "application" in the phrase "application 

guard" of the independent claims, which implies that the securable component being 

guarded is in some way associated with an application. 

The Examiner proposed "allowing" for a combined Nessett et al and Minear et al. 

system. However, Nessett et al. states, 

Although products exist that provide for estabhshing security in particular product 
families, systems which take advantage of products in all the various categories of 
devices found in networks, require substantial administration. In a network 
involving a wide variety of network intermediate devices and terminals, an 
administrator is required to manage the establishment of security policy at all the 
various levels of protocol, and in all the various systems. 
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In other words Nessett et al teach that the combined use of multiple security systems 

(e.g., that of Nessett et al combined with Minear et al.) is difficult for an administrator to 

handle and should be avoided. Nessett et al also states 

However, the variety of security features, and the various devices and 
levels of protocol at which they operate, present a significant administration 
problem to users of the security features. Because of the complexity, it is difficult 
to establish a coordinated security pohcy across all layers, and device types of the 
network, and particularly difficult to maintain such a system even if it could be 
successfully implemented. 

Thus Nessett et al. in addition to trying to avoid using multiple security systems is trying 

to avoid having different security systems operating at different levels because of further 

administrative difficulties this creates. Minear et al.'s security system operates at the IP 

layer (the columns 3 lines 57-62). In contrast Nessett et al.'s system chooses the layer or 

layers at which to operate according to the components involved (column 3, Unes 20-67). 

Nessett et al operates at multiple layers that are different at different parts of the system 

(column 4, lines 3-7) leading to a likelihood of having Minear et al, sometimes operating 

at a different layer than Nessett et al and sometimes operating at a common layer, thereby 

creating at least some places that generate the administrative difficulties Nessett et al. is 

trying to avoid and would be a move away fi-om the coordinated security approach sought 

by Nessett et al. 

Nessett et al fiirther teaches away fi*om having redundancies (column 3, lines 64- 
67). Combining the system of Minear et al. with Nessett et al would seem to be likely to 
result in undesirable redundancies at the IP layer. 

Regarding claims 2, 3, 20, 39 and 40 the Examiner cited feature 1 1 of FIG. 1 and 
column 12, lines 34-37. However, the applicants respectfully submit that feature 1 1 of 
FIG. 1 and column 12, lines 34-37 do not explain any distribution mechanism. Claims 3, 
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20 and 40 specify a distributor for distributing the policy and further specify that the 
distributor is part of the poHcy manager. Even if Nessett et al. has a distributor it is not 
clear that it would be part of their policy manager, as required by claims 3, 20, and 40. 
Further feature 1 1 of FIG. 1 is a "network management station" rather than a "security 
management station" as specified by claims 2 and 39 from which claims 3 and 40 depend 
and as specified by claim 20. Column 12, lines 34-37 discuss a security policy 
"language" rather than a security policy (as in claim 2) or a global policy (as in claims 20 
and 39) being edited via a management station as opposed to using a standard word 
processing editor to edit or write the source code, Possibly the systems administrator 
needs to edit the source code of a program that uses this language, and there is no security 
management station that allows for both editing and setting global or security policy. 
The Applicants respectfully request clarification as to how column 12, lines 34-37 imply 
or suggest the use of a security pohcy management station for both setting and editing 
global policy or security poHcy. 

Regarding claims 11, and 37 the Examiner cited column 6, lines 12-34, However, 
column 6, lines 12-34 never mentions an application guard or authentication engine as 
required by claims 1 1 and 34 to be placed on a cHent server. 

Regarding claims 6, 21 and 43, the "database management system" of column 9, 
lines 7-11, cited by the Examiner manages the "topology data base" of line 7 and is not a 
database management system of the claims. The topology database keeps track of the 
topology of the system as impHed by its name. Thus the database management system 
(of line 8) is not for "maintaining" security pohcy as in claims 6, 21, and 43, Column 9, 
hues 23-27, cited by the Examiner, is under the heading of and therefore discusses the 
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"Security management back end" (column 9, line 16) rather than the database 
management system of line 8, The backend "translates" within the "context" of the 
topology database (column 9, lines 23-27), In other words the backend translates the 
pohcy using the topology database for the information about how the nodes are 
connected to one another rather than a database management system maintaining the 
security policy, as claimed. 

Regarding claims 7, 28, and 46 the Examiner stated. 

Thus the security policy establishes configuration data in a repeater by updating a 
management node (column 12, lines 45-56). 

The Apphcants respectfully fail to see how the encryption of data sent between frames 

discussed in column 12, lines 45-56, cited by the Examiner, is related to optimizing the 

policy as claimed. Although encryption may enhance the impenetrability of the firewall, 

the policy relates to things such as whom can access which part of the system, for 

example, rather than the format used to send the data. Therefore encryption is not a way 

of optimizing the policy. 

Regarding claims 9 and 25, the Examiner cited column 8, hnes 7-14 and column 
12, lines 26-31, however these lines do not address placing an additional application 
guard at each client as claimed. 

It would appear that claim 19 should have been grouped with claims 9 and 25 
rather than with claims 10, 26 and 36, Clarification is respectfully requested. 

Regarding claims 10, 17, 26, 30, 36, and 47 the Examiner first asserts that the 
combination is obvious, next lists the features of the combination, then asserts that the 
two references are with in the same field of endeavor, and then concludes that 
"Accordingly" the combination would have been obvious. However, the Examiner failed 
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to provide a motivation for the combination. Alleging that two references are within the 
same field of endeavor does not provide a motivation for the combination. 

Regarding claim 1, the Examiner stated that "the Application level gateway serve 
as a guard/' while regarding claims 10, 19, 26, and 36 the Examiner stated, "all network 
traffic must pass through one of the proxies." It is not clear why the Examiner mentions 
the proxies. If the Examiner was trying to allege that the proxy is the apphcation guard, 
he is contradicting his earlier allegation that the gateway firewall application 1 8 is the 
application guard. If the Examiner was alleging that the proxy is the claimed interface, 
then it is not clear why he mentioned the encryption interface. The encryption interface 
is not the interface of the claims because the interface of the claims is for requesting 
access to securable components while the encryption interface, "Crypto interface 80 [is] 
used to encrypt an IPSEC payload" (column 11, lines 46-48), 

It would also appear that claim 34 should not have been grouped with claims 12, 
24 and 44. The Apphcants respectfully fail to see how the Examiner's discussion of 
claims 12, 24, 34 and 44 is relevant to claim 34. Clarification is respectfully requested. 

Regarding claims 17, 30 and 47 eve if arguendo Minear et al, teach an application 
guard they clearly cannot teach an apphcation guard that guards the policy manager (as 
opposed to one that guards other securable components) because the pohcy manager the 
Examiner relied upon is in Nessett et al 

Regarding claims 18 and 42 it is not seen where the Examiner finds a suggestion 
to use a local application guard that is distributed by the policy manager. The proxies of 
Minear et al. are not disclosed as being distributed locally implying that they are all 
located in the same location. 
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Regarding claim 53 and 54 column 6, lines 32-34, cited by the Examiner (towards 
the top of page 10), do not discuss the processor and therefore do not disclose the same 
processor distributing the policy and executing the policy manager. 

The Examiner rejected claims 5, 14, 15, 22, 32, 41, 45, and 49 under 35 USC 
§ 103(a) as unpatentable over Nessett et al. in view of Minear et al. as appHed to the 
above claims further in view of Abraham et al. 

Regarding claims 5, 22, 32, 41, and 49, the Examiner cited column 7, lines 38-43 

and column 9, lines 1-10 and then stated, 

By monitoring the user transactions the policy management administrator would 
be able to better customize policies. This would have motivated one of ordinary 
skill in the art to implement the modifications set forth above. 

However, the Examiner never provides support for this statement. The motivation to 

combine or modify a reference must also have support. The Applicants hereby 

respectfully call upon the Examiner to provide support for this statement in accordance 

with 37 CFR 1.104 d(2)or provide a reference in accordance with the last sentence of the 

second paragraph of MPEP 2144.03. 

The Applicants respectfully note that the Examiner's discussion of claims 5, 22, 
32, 41, and 49 fail to expHcitly address the "audit log" of claim 32. 

The Examiner stated regarding claims 14, 15, and 45, 

It would be obvious to allow the combination of Nessett and Minear to implement 
the system taught by Abraham. This implementation would allow Nessett 
distribution system used by the administrator, to be controlled by menu sets. This 
would offer a more efficient means for network management of the security 
policy system. 

However, the Applicants respectfully submit that the Examiner never provides support 
that efficiency is in anyway recognized to be related to menus. The Applicants 
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respectfully call for the Examiner to provide support for this statement under 37 CFR 
LI 04 d(2) or a reference in accordance the last sentence of the second paragraph of 
MPEP 2144.03. 

The Examiner continued, 

One of ordinary skill in the art would have recognized that this combination 
would give the management abilities to analyze, edit, distribute and view audit log 
stored on the audit server. 

However it is not clear that there is an audit log on an audit server in Abraham et al. It is 

not clear what would motivate the addition of an analyze option on the menu that 

Abraham never mentions, even assuming arguendo that it is present. It is not clear what 

support the Examiner has for the allegation that one of ordinary skill would have 

recognized that this combination would give management the abiUty to analyze and view 

an audit log. The Applicants respectfully call for the Examiner to provide support for 

these allegations under 37 CFR 1 .140 d(2) or a reference in accordance the last sentence 

of the second paragraph of MPEP 2144.03. 

Regarding claims 14, 15, and 45 the Examiner alleged that Nessett et al. teach the 

use of an "audit log" and cited column 13, lines 32-38. However, although Nessett et al. 

column 13, lines 32-38 state that 

repeaters . . . can monitor port disconnects and reconnects, reporting these to 
network management applications, 

Nessett et al fail to state that the ^'disconnects" and ''reconnects" monitored and reported 

are recorded in an audit log. The words record and log are absent from Nessett et al.'s 

specification. 

It is not clear that the options provided in column 12, lines 15-44, cited by the 
Examiner, are in a menu format as required in the claims. It is not clear if Abraham et al. 
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provides a distributed policy option. Possibly the newly edited policy only gets 
distributed after closing the window and/or after rebooting the system or network. As the 
burden of establishing a prima fascia case of obviousness is upon the Examiner, it 
logically follows that the burden is upon the Examiner to establish that Abraham et al 
suggest an explicit menu option of distributing policy. 

Regarding claim 15, Abraham et al never discloses a menu including all of the 
options listed, i.e,, navigate tree, analyze poUcy, edit poHcy, distribute policy, and view 
audit log. In particular, none of the references cited teach or suggest a menu option of 
analyze pohcy or view audit log. 

The Examiner rejected claims 13 and 27 under 35 USC § 103(a) as unpatentable 
over Nessett et al. in view of Minear et al. as applied to claim 1 further in view of Rogers 
et al. 

In making this rejection the Examiner stated, 

Rogers does not specifically teach the loader as being al [sic] loader for bulk 
policies. It would have been obvious to one of ordinary skill in the art to 
recognize that in the event of the administrator wanting to load numerous policies 
the policy management system would be equipped to handle such an occurrence. 

In other words the Examiner first recognized that Rogers et al. lacks a teaching for the 

element (the bulk policy loader) missing from the modified device of Nesset t et al. and 

first needs to modify Rogers et al. to have this missing component. After modifying 

Rogers et al. the Examiner stated. 

It would have been obvious ... to allow the combination system [that of Nessett et 
al combined with Minear et al,] to implement the means of a policy loader as 
suggested by Rogers et al. 

However, the policy loader of Rogers et al. is the wrong poHcy loader. In other words the 

Examiner is assuming that obvious to include a device, that does not actually exist but is 
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obvious over a second device, within a first device is obvious. The Apphcants 
respectfully submit that the added level of foresight required to envision the modified 
second device that does not yet exist and the added foresight required to envision the 
behavior, potential benefits and pitfalls of this presently nonexistent device is beyond the 
standard of obviousness of 35 USC §103. The situation is somewhat analogous to a 
chess game. After any given move it can be argued that finding any and all of the next 
possible moves for a first player is obvious. The first player just needs to take each of his 
pieces one at a time and check each space along each possible direction of movement to 
find all possible next moves. Further after the next move has been made (no matter 
which move was chosen) to find all the possible moves of the next player is also likewise 
obvious by following the exact same process. Following this simple algorithm all 
possible game scenarios could be mapped out. Further, if the first player were to have all 
his possible game scenarios mapped out selecting which move gives the best outcome is 
also usually obvious. Yet, making the best next chess move is often far fi:-om obvious 
because of the tremendous foresight required to complete this sequence of obvious 
mappings and selections. Even selecting the move that will generate the best outcome 
were the game abruptly terminated after the next couple of moves is usually also far from 
obvious because of the foresight required. Likewise the foresight required to see all the 
possibilities after modifying a device to see the benefits and to see how to overcome 
potential obstacles in taking the nonexistent modified device and combining it with 
another nonexistent modified device is typically beyond obviousness. 

The Examiner stated that combining the nonexistent modified device of Rogers et 
al. with the nonexistent modified device of Nessett et al. is bovious 
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because Rogers teaches an invention similar to Nessett in that they both are 
directed towards poUcy management within a network system, and one of 
ordinary skill in the art would have recognized these similarities and concluded 
that they are form [sic] the same field of endeavor. This would have motivated 
one of ordinary skill in the art to implement the modifications set forth above. 

In other words the Examiner alleged that (1) Rogers et al. and Nessett et al. are analogous 

art and (2) the motivation to combine these two nonexistent modified devices is that they 

are analogous art. However, the Applicants respectfully submit that the fact that two 

prior art devices are analogous art is not a sufficient motivation to combine to prove 

obviousness under 35 USC §103 but is just a prerequisite for using the prior art device in 

question. 

Rog;ers et al.'s invention relates to administration systems (column 1, lines 10-14) 
and to policies for managing an entire system rather than policies that just apply one type 
of task such as enforcing security. Rogers et al.'s invention provides a policy 
implementation system that responds to changes in the network by providing threads 
representing event driven statements. The reason for doing this is because the written 
pohcy that would otherwise need to be implemented by operators often requires 
monitoring the state of the system. Rogers et al. discusses that implementation of 
poKcies often include complex rules for when to do which procedure. Rogers et al. 
further discuss that sequences of operations may change depending on the outcome of 
previous operations (column 1, lines 58-64). These problems are not very relevant to 
simpler policy managers such as those of Nessett et al,, which just enforce access rights 
of workers, for example, and do not have many different types of sequences of operations 
that need to be changed depending on the outcome of other sequences of events. 
Consequently, the Applicants respectfully submit that Rogers et al does not provide a 



38 




sufficient motivation for combining his device with that of Nessett et al, with or without 
their respective proposed modifications. 

Further ahhough column 12 Unes 15-44 of Rogers et al. cited by the Examiner 
may mention changing the policy, it never discusses "loading" the poHcy as claimed. 
The word "load" and variations of it never appears in the text of Rogers et al. "Loading" 
a policy implies importing a policy that has already been entered somewhere (e.g. in a 
file) as opposed to merely being entered via keyboard directly into the program. Thus the 
combination proposed by the Examiner fails to suggest loading the poHcy, as claimed. 
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Summary 

In numerous places the Examiner appears to use an improper standard of obvious 
to "allow" to combine as a standard of obviousness and implies that because two 
references are combinable or within the same field of endeavor therefore it is obvious to 
combine them, which is inconsistent with established case law. 

In several places the Examiner provides motivations for combining references that 
are not found within the prior art. The Applicants respectfully request the Examiner to 
either provide support for these statements under 37 CFR 1.104 d(2) or provide a 
reference in accordance with the last sentence of the second paragraph of MPEP 2144,03. 

Nessett et al. are trying to avoid redundancies and having multiple security 
systems operating at multiple levels both of which are likely outcomes of combining the 
security systems of Nessett et al and Minear et al, mitigating against making this 
combination in the manner proposed by the Examiner. 

The AppUcants have specifically pointed out several places the Examiner alleged 
certain features are disclosed by the references but upon a closer look the passages cited 
do not appear to fully support the Examiner's assertions. For example, the Applicant 
respectfully submit that it is not clear which claimed elements the Examiner believes 
correspond to which features of the references relied upon regarding the proxy, the 
encryption interface and the application level gateway. The proxies of Minear et al are 
not disclosed as being distributed locally implying that they are all located in the same 
location. The Applicants respectfully submit that a topology management system is not 
the same as the claimed management system for maintaining security. Abraham et al do 
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not disclose a menu including a log option and an analyze option. The Applicants 
respectfully request either a clearer explanation or withdrawal of the rejections affected. 

Regarding claims 13 and 27, the proposed modification of Nesset et al. with the 
modified device of Rogers et al assumes that obvious to modify a first device with a non- 
existent second, where the nonexistent second device is an obvious modification of a 
third device, is obvious. However, the Applicants respectfully submit that in the present 
case more foresight is required than is justified under obviousness of 35 USC §103 for 
such a compound modification. 

Rogers et al.'s concerns regarding changes in sequences of operations do not 
seem very relevant to the simpler system of Nesset et al. and therefore do not provide a 
sufficient reason for making the compound modification proposed by the Examiner. 

In conclusion, Apphcants respectfully submit that the claims are allowable, and 
therefore request that the Examiner withdraw the rejections and pass the application to 
issue. If the Examiner has questions regarding this case he is invited to contact 
Applicants' undersigned agent. 
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